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Abstract 

Programming languages are expected to support programmer's effort 
to structure program code. The ML module system, object systems and 
mixins are good examples of language constructs promoting modular pro- 
gramming. Among the three, mixins can be thought of as a generalization 
of the two others in the sense that mixins can incorporate features of ML 
modules and objects with a set of primitive operators with clean seman- 
tics. Much work has been devoted to build mixin-based module systems 
for practical programming languages. In respect of the operational seman- 
tics, previous work notably investigated mixin calculi in call-by-name and 
call-by-value evaluation settings. In this paper we examine a mixin cal- 
culus in a call-by-need, or lazy, evaluation setting. We demonstrate how 
lazy mixins can be interesting in practice with a series of examples, and 
formalize the operational semantics by adapting Ancona and Zucca's con- 
cise formalization of call-by-name mixins. We then extend the semantics 
with constraints to control the evaluation order of components of mix- 
ins in several ways. The main motivation for considering the constraints 
is to produce side effects in a more explicit order than in a purely lazy, 
demand-driven setting. We explore the design space of possibly interesting 
constraints and consider two examples in detail. 

1 Introduction 

Modularity is an important factor in the development of large programs. In 
particular programmer's effort to logically organize program code is of great 
importance in the long run to maintain, debug and extend the program code. 
Many modern programming languages have mechanisms to support this effort by 
facilitating modular development of programs. Examples of these mechanisms 
are object systems and the ML module system. 

Being ML programmers, we enjoy the rich expressivity of the ML module 
system for modular programming. Nestable structures allow us to hierarchically 
organize namespaces and program code. With signature constraints, we control 
visibility of components of structures. In particular the combination of nesting 
and signature constraints offers fine grained visibility control, as witnessed, for 
example, by the Moby programming language Fisher and Reppy(1999)| . Func- 



tors, which are functions on modules, facilitate code reuse in a modular way. 
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Although functors might not be as pervasive as nesting or signature constraints 
in our programs, they play a critical role in some contexts. Good examples are 
Map. Make and Set. Make functors as implemented in OCaml's standard library. 

However ML does not have recursive modules. That is, neither recursive 
functions nor types can be defined across module boundaries. As a result of this 
constraint, programmers may have to consolidate conceptually separate compo- 
nents into a single module, intruding on modular programming |Russo(2001)] . 
Compared to ML, object systems have excellent support for recursion across 
object/class boundaries. Particularly in the presence of late-binding, object 
systems facilitate the development of extensible programs, where recursively 
defined types and functions may need to be extended together. Typical such 
scenarios are condensed in the notorious expression problem Torgersen (2004)1 ■ 



We expect a module system to support all the familiar features of ML mod- 
ules as well as recursion between modules and late-binding. There are at least 
three approaches to design such a module system. Two of them are to extend the 



ML module system with recursion Crary et al.(1999)Crary, Harper, and Puri 



and to extend object systems with nesting, abbreviation and type members 



Odersky et al.(2003)Odersky, Cremet, Rockl, and Zenger] . The third approach 



is to develop another form of a module system, namely mixins. In this paper 
we follow this third approach. 

The concept of mixins is first introduced in the context of object systems 
[Bracha(1992)| , then is extended to in the context of ML-style modules. A 
mixin is a collection of named components, where each component can be either 
defined (bound to a definition) or deferred (declared without definition). Two 
key operations on mixins are the sum and freeze operations; the former takes 
two mixins and composes a new mixin by merging the two, and the latter 
resolves, or links, deferred components of a mixin to defined ones. The sum 
operation is reminiscent of functor application in ML and inheritance in object 
systems. However more flexibility is obtained by separating the resolution from 
the sum operation. The freeze operation is free to resolve a deferred component 
to a defined one independently of their names at any point, as long as their 
types match; notably it can liberally tie a recursive knot inside a mixin. Indeed 
mixins are designed to be a generalization of ML-style modules and objects, 
by incorporating features of both with a set of primitive operators with clean 
semantics [Bracha(1992) Ancona and Zucca(2002)] . 



Two challenging problems remain to replace ML-style modules with mixins, 
namely type checking and initialization. In this paper, we address the latter 
problem. Promising progress has been made in designing a type system for 
mixins with type components and a signature language to enforce type abstrac- 
tion between mixins [Odersky et al.(2003)Odersky, Cremet, Rockl, and Zenger 



Owens and Flatt(2006)| ; we expect to benefit from the previous work for the 



former problem. 

Initialization of mixins poses an important design problem if we are to build 
a mixin-based module system on top of a call-by- value core language supporting 
arbitrary side-effects, such as the ML core language. The main difficulty stems 
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from unconstrained recursive definitions such as let rec x = x that the core 
language does not allow but that might result from the freeze operation. We 
need an initialization semantics for mixins which takes account of unconstrained 
recursion consistently with the call-by-valuc semantics of the core language; this 
is the subject of this paper. 

Ancona and Zucca's mixin calculus Ancona and Zucca (2002)1 , called CMS, 



is one of the most influential work in formalizing an operational semantics for 
mixins. The formalization is elegantly concise and the paper illustrates how 
mixins support various existing constructs for composing modules, found in the 
ML module system, object-systems and linking calculi [Cardelli(1997)| , well- 
explaining why we claim mixins arc a generalization of other modular systems. 
Inspired by CMS, Hirschowitz and Leroy examined a mixin calculus in a call- 
by-value setting to build a mixin-based module system on top of the ML core 
language. The original call-by-name semantics of CMS might not be well-suited 
for the call-by-valuc cffcctful ML core language; CMS admits recursive defi- 
nitions such as let rec x = x, causing the evaluation to diverge when x is 
selected, and it can produce the same side-effect repeatedly. Neither behavior 
is consistent with the semantics of ML. 

In this paper we examine a mixin calculus in a call-by-nced, or lazy, eval- 
uation setting with a back-patching semantics. Broadly wc model mixins as 
nestable records with lazy fields. In the simplest setting which we examine in 
Section [21 a component of a mixin is evaluated when it is selected. We explain 
how side-effects are duplicated and linearly produced by open and closed mixins 
respectively, while allowing both open and closed mixins to be merged indiscrim- 
inately; this tolerance of merging mixins of different status is our important de- 
sign choice, which is different from previous proposals Hirschowitz and Leroy(2005)[ 



Ancona et al. (2003) Ancona, Fagorzi, Moggi, and Zucca . In Section [^TTl we ex- 



emplify how the tolerance can be useful. 

Then in Section IH we extend the former semantics of Section [3] with an abil- 
ity to constrain the evaluation order of components of mixins. While the former 
semantics admits the most flexible recursive initialization patterns for mixins, 
the flexibility can do harm because of the intrinsically implicit evaluation or- 
der determined at run-time in a demand-driven way. It may be interesting to 
constrain possible initialization patterns, making the evaluation order more ex- 
plicit. For instance, we may want to enforce top-down evaluation order within 
mixins, where components of a mixin are evaluated following the textual def- 
inition order in the source program. Or, we may want to keep the invariant 
that once a component of a mixin is selected, all its components are eventually 
evaluated. Indeed our ultimate goal is to flnd the most beneficial constraint 
on the evaluation order that still admits interesting recursive initialization pat- 
terns, but that makes the evaluation order more explicit, thus more predictable 
to programmers. 

In this paper we do not propose a particular constraint; simply we do not yet 
have enough experience in programming with mixins to decide what constraint 
is best in practice. Hence we formalize the operational semantics so that it deals 
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with several constraints. Concretely, we give a constraint language and extend 
the semantics of Section[3]to evaluate components of mixins according to a given 
constraint expressed by the constraint language. We explore the design space of 
possibly interesting constraints and examine two particular constraints in detail 
as examples. 

Contributions of the paper are summarized as follows. We formalize the 
operational semantics for a lazy mixin calculus (Section [3]), by moderately 
extending Ancona and Zucca's formalization of a call-by-namc mixin calcu- 
lus Ancona and Zucca(2002)| . We demonstrate how lazy mixins can be useful 
in practice through examples (Section ^ . Then wc extend the semantics to be 
able to control the evaluation order of components of mixins in several ways 
(Section |4]) and exemplify concrete scenarios where particular evaluation strate- 
gies are enforced by constraints. We believe the ability to deal with several 
evaluation strategies is a novelty of the formalization and the formalization 
serves as a basis for exploring the design space. 



2 Examples 

In this section, we introduce our lazy mixin calculus through a series of examples. 
Many constructs of the calculus come from CMS [Ancona and Zucca(2002)] . 



Examples are written in a more programmer-friendly surface syntax and we 
assume a small subset of the OCaml core language for the core language of the 
mixin calculus. We recall that the OCaml core language adopts a call-by-value 
evaluation strategy and supports arbitrary side-effects within (core) expressions. 



2.1 MakeSet and MakeMultiSet mixins 

We start by looking at possible mixin equivalents to MakeSet and MakeMultiSet 
ML functors and their instances by the Key structure, as given in Figure [TJ 
MakeSet and MakeMultiSet are functions on ML structures, or functors, for 
making sets and multi-sets of integers, internally represented as lists and lists of 
lists respectively. Both take as argument a structure containing a create function 
for producing integers out of nothing and a compare function for comparing 
given two integers. MakeSet extends this functionality to sets of integers and 
MakeMultiSet does for multi-sets. Then wc apply the two functors to the Key 
structure to instantiate customized Set and MultiSet structures. 
Below is a mixin equivalent to the MakeSet functor: 

mixin MakeSet = { 
val create_element : unit int 
val compare_element : int int int 
let create () = [ create_element () ] 
let compare si s2 = compare_element ... } 

A mixin structure is a sequence of named components, where a component 
may be defined like create and compare or deferred like create_element and com- 
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module MakeSet = functor (X : sig 
val create : unit int val compare : int int 
struct 

let create () — [ X. create () ] 

let compare si s2 — X. compare ... 

end 

module MakeMultiSet — functor(X : sig 
val create : unit — > int val compare : int int 
struct 

let create () = [[ X. create () ]] 
let compare si s2 = .... X. compare ... 
end 

module Key — struct 

let count — ref (-1) 

let create () = incr count; Icount 

let compare x y = 
if X = y then else if x < y then 1 else (-1) 
end 

module Set = MakeSet(Key) 
module MultiSet = MakeMultiSet(Key) 

Figure 1: MakeSet and MakeMultiSet ML functors 

pare_element. The bodies of defined components can refer to names of deferred 
components as if they were present. Similarly, below is a mixin equivalent to 
the MakeMultiSet functor: 

mixin MakeMultiSet = { 

val create_element : unit int 

val compare_element : int int int 

let create () — [[ create_element () ]] 

let compare si s2 — compare_element ... } 

We build a mixin equivalent to the Key structure in two steps: 

mixin FKey = { 

let count = ref (-1) 

let create_key () = incr count; Icount 

let compare_key x y = 
if x = y then else if x < y then 1 else (-1) } 
mixin Key = close(FKey) 

Wc distinguish two states of niixins: open and closed. Intuitively a closed mixin 
is a record with lazy fields, whereas an open mixin is a function which returns a 
record with lazy fields. Intended implications of this comparison arc 1) projec- 
tion of components is only possible from closed mixins, but not from open mix- 
ins; 2) an open mixin can be instantiated to create closed mixins; 3) side-effects 
contained in a closed mixin are produced exactly once, whereas side-effects in 



int end) 



int end) 
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an open mixin are produced as many times as the mixin is instantiated. FKey 
above is an open mixin, and Key is a closed mixin instantiated from FKey by 
the close operation. A projection Key.create.key is legal, but FKey.create_key is 
not. As expected, the counter Key.count is initialized to -1 exactly once. 
We may close the FKey mixin again: 

mixin Key2 — close(FKey) 

Counters Key.count and Key2. count arc distinct from each other. For instance, 
calling Key.create docs not increase Key2. count. 

The close operation is only available for mixins without holes, or mixins 
which do not contain deferred components. The freeze operation, possibly com- 
bined with the sum operation, is used to fill in the holes. For instance, below we 
merge Key and MakeSet mixins by the sum operation, then resolve the deferred 
components create_element and compare_element of MakeSet to the defined com- 
ponent create_key and compare_key of Key respectively by the freeze operation, 
to fill in the holes of MakeSet: 

mixin FSet' — Key ^ MakeSet 

mixin FSet = freeze^ (FSet') 

where ip is the following mapping: 

( create_element create_key; 
compare_element ^ compare_key ) 

Now FSet docs not contain holes, hence we can close it: 

mixin Set — close(FSet) 
We do the same for MakeMultiSet in one step this time: 

mixin Multiset = close(freeze^,(Key ^ MakeMultiSet)) 

Set and MultiSet mixins are equivalent to Set and MultiSet ML structures as 
given in Figure [TJ 

It is important to see differences resulting from closing FKey after merging 
it with MakeSet and MakeMultiSet as follows: 
mixin Set' = close(freeze,/,(FKey ^ MakeSet)) 
mixin MultiSet' — close(freeze0(FKey <— MakeMultiSet)) 

Here FKey is instantiated twice. While Set and MultiSet share the same counter. 
Set' and MultiSet' have distinct counter's. As a result, calling Set. create affects 
both results of the next calls to Set. create and MultiSet. create, while calling 
Set'. create only does the result of the next call to itself. 



2.2 Widget mixins 

Many GUI programming APIs involve recursive initialization patterns to form 
mutually referential graphs among related widgets in the style of create-and- 
configure, as Syme calls in Syme(2005)| . In that paper he explains how recur- 

^ Only in this section, we use angle brackets instead of square brackets to denote mappings 
to avoid confusion with list expressions. 
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sive initialization patterns are prominent in GUI programming and proposes 
a semi-safe lazy evaluation strategy for the ML core language to tame ML's 
value recursion restriction; the restriction constrains right-hand sides of recur- 
sive definitions to be syntactic values, thus may hinder uses of sophisticated 
GUI programming APIs. In this subsection, we consider a GUI example similar 
to his in a lazy mixin setting. 

Wc assume given the following interface of the API: 

type form type formMenu type menultem 

val createForm: string form 

val createMenu: string formMenu 

val createMenultem: string — * menultem 

val toggle : menultem unit 

val setMenus : form * formMenu list unit 

val setMenultems : formMenu * menultem list unit 

val setAction : menultem * (unit unit) unit 

The API requires the create-and-configure initialization pattern where widgets 
are first created, then explicit mutation configures a relation between the wid- 
gets. Below we build boiler-plate mixins which encapsulate the create-and- 
configure pattern: 

mixin Form = { 

val name : string 

val menus : formMenu list 

let form = createForm(name) 

let _ — setMenus(form, menus) } 
mixin Menu — { 

val name : string 

val items : menultem list 

let menu — createMenu(name) 

let _ = setMenultems(menu, items) } 
mixin Menultem — { 

val name : string 

val other : menultem 

let item — createMenultem(name) 

let _ — setAction(item, fun () toggle(other)) } 

Then we use them: 
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MyForm — 

hidename(freeze(p3meH^name)(Form ^ { let name = "Form" })) 
MyMenu = 

hidename(freeze(n3^ei-^name)(Menu ^ { let name = "Menu" })) 
Mylteml = 

rename((otheri-»item2),{itemli-»item)) (hidename( 

freeze^nameH^name) (Menultem ^ { let name — "Rice" }))) 
Myltem2 = 

rename((otheri-^iteml),{item2i-^item))(hidename( 

freeze^namei-^name) (Menultem ^ { let name = "Grape" }))) 
MyGUI = 
close(freeze,0j ( 
Mylteml ^ (Myltem2 ^(MyMenu ^MyForm)))) 

where ipi is the following mapping: 

( iteml 1-^ iteml; item2 i-^ item2; 
items 1-^ [iteml; item2] ; menus [menu]) 

Above we have introduced two new constructs. The hide operation hidex(Af) 
hides the component named X of the mixin M by making the component invisi- 
ble outside. The rename operation rename^^^ ^^^(M) changes names of deferred 
and defined components of the mixin M by 0i and (f>2 respectively, where (f>i 
and (1)2 are finite mappings on names of component^ For instance, in the def- 
inition of Mylteml, the deferred component other is renamed to item2 and the 
defined component item to iteml. Observe the opposite directions of mappings 
(other 1-^ item2) for deferred components and (iteml item) for defined ones. 
This adds flexibility of the rename operation in that when (pi maps deferred 
components of distinct names to the same name, then the components can be 
resolved simultaneously, and that when 02 maps two distinct names Xi and X2 
to a single name X, then the component which was named X can now pro- 
jected by either Xi or X2. Thanks to the renaming, Mylteml and Myltem2 can 
be merged to form MyGUI without causing name clash; a deferred component 
and a defined component of a mixin can have the same name, but a deferred 
(resp. defined) component must not have the same name as other deferred 
(resp. defined) components. Besides, we have used the freeze operation in a 
more flexible way by mapping a name of a deferred component to an expression 
composed of names of defined components, for example [iteml; item2]. 

The above example builds a GUI application forming a widget contain- 
ment hierarchy where MyForm contains MyMenu, which contains Mylteml and 
Myltem2. Mylteml and Myltem2 are mutually recursive; each toggles the activa- 
tion state of the other. We hide the name component of mixins to be merged to 
avoid name clash. Anonymous (under-scored) components do not contribute to 
name clash; they would be implemented as syntax sugar via the hide operation. 
Renaming of other and item components of Mylteml and Myltem2, both of which 

■^In the formalization, we will distinguish o-convertible identifiers (internal names) and 
non-convertible names (external names). Then ipi and 02 are mappings on names, not on 
identifiers. 
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are derived from the same mixin Menu Item, is necessary for cross-connecting the 
deferred component of one to the defined component of the other. In the last hne 
we sum up the constituent mixins and resolve deferred components to defined 
ones, configuring the widget containment hierarchy. 

This example suggests it can be useful to control the evaluation order of 
components of mixins, instead of evaluating them purely lazily in a demand- 
driven way, i.e. evaluating only the components that are projected. Indeed we 
would like to make sure the widget containment hierarchy has been properly 
configured before MyGUI is actively used. For that purpose, all the anonymous 
components of MyGUI must be evaluated before any of its components becomes 
externally accessible. In Sectional we present the operational semantics which 
can enforce such constraint on the evaluation order. 



2.3 A combinator library for marshallers 

The last example deals with marshallcr combinators and is motivated by Syme's 
paper again [Syme(2005)| . Kennedy introduced a functional- language com- 
binator library for building marshallers and unmarshallers of data structures 
[Kennedy(2004)| . The essential ingredient of his proposal is the tying together 
of a marshaller and unmarshaller pair in a single value. Then the consistency 
of marshalling and unmarshalling is ensured by construction. The original pro- 
posal of Kennedy is implemented in Haskell. Porting the code to ML is mostly 
easy, except for a couple of wrinkles. The value recursion restriction of ML is a 
source for the wrinkles and requires cumbersome workaround for an ML version 
of the combinator. In this subsection, wc rebuild a combinator library for mar- 
shallers using lazy mixins with ML as the core language and demonstrate how 
the use of lazy mixins avoids the value recursion problem. In the following ex- 
amples we assume a richer mixin language where a mixin may contain deferred 
and defined types as components, although our formal development docs not 
consider mixins with type components. Type checking of mixins is not in the 
scope of the paper. As far as our examples are concerned, existing type systems 
are sufficient Flatt and Felleisen(1998)| . 



Wc consider a mixin-based combinator library with the specification given 
below. A mixin signature mixin M : { type t val x : t } ^ { type s = t * t val y : s 
} specifies an open mixin with deferred type component t and value component 
X of type t, written in the left-hand side of the arrow, and with defined type 
component s satisfying type equation s = t * t and value component y of type 
s, written in the right-hand sidcH. The scope of type names declared in the left 
hand of the arrow extends to the right hand. 



^This signature language is designed only for the sake of the examples. A more practical 
signature language is proposed, for instance in [Owens and Flatt(2006)] . 
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type channel 
type a marshaller 

val marshal : a marshaller a * channel unit 
val unmarshal : a marshaller channel a 
mixin PairMrshI : 

{ type si type s2 
val mrshll : si marshaller val mrshl2 : s2 marshaller } 

{ type t = si * s2 val marshaller : t mrshi } 
mixin ListMrshI : 

{ type elm val mrshLelm : elm marshaller } 
{ type t = elm list val mrshI : t marshaller } 
mixin InnerMrshI : 

{ type src type trg val f : src ^ trg val g : trg — ^ src 

val mrshLsrc : src marshaller } 
{ type t — trg val mrshI : t marshaller } 
mixin IntMrsh : 

{} ^ { type t — int val mrshI : t marshaller } 
mixin StringMrsh : 

{} ^ { type t — string val mrshI : t marshaller } 

IntMrsh and StringMrsh mixin have an empty deferred component. But they are 
still open mixins, thus needs to be closed for making their components accessible. 

The abstract type marshaller could be internally implemented as a record 
consisting of a marshalling action and unmarshalling action: 
type a marshaller = { marshal: a * channel — > unit; 

unmarshal : channel a } 
Recall that it is important for consistently building marshallers and unmar- 
shallers that a marshaller is a single value, but not two separate functions. In 
this way, users of the library can only build consistent marshaller /unmarshaller 
pairs. 

We do not present further details of how the library can be implemented. 
In the original paper [Kennedy(2004)| , Kennedy explains an excellent imple- 
mentation which lets the programmer control sharing of the marshaled data. 
Transposing marshaller combinators for constructed types such as pairs and 
lists, originally implemented as functions, to mixins is straightforward. For 
instance, a hmction-based marshaller combinator pairMrshl(mrshll, mrshl2) of 
type (si marshaller) * (s2 marshaller) (si * s2) marshaller for constructing a 
marshaller for a pair from marshallers of the components can be translated into 
a mixin as follows: 
mixin PairMrshI = { 
type si type s2 

val mrshll : si marshaller val mrshl2 : s2 marshaller 
type t = si * s2 

let mrshI = (* the body of pairMrshl(mrshll, mrshl2) *) } 

Now we turn to how to build custom-marshallers for user-defined data types. 
We first build marshallers for both a single file, represented as a pair of an integer 
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and string, and a list of files: 
type file = int * string 
mixin FileMrshI — freeze*( 
(rename(0,(3i^t.^,3hiiK^mrshi))(lntMrshl)) ^ 
(rename(0,(52H^t:mrshi2K^mrshi))(StringMrshl)) ^ PairMrshI)) 
mixin FilesMrshI = freeze*( 
(rename(0_(eim*^t;mrshLeimH^mr5hi))(FileMrshl)) <- ListMrshI) 
The notation denotes an empty mapping. Above we have introduced a high- 
level mixin construct freeze*, which resolves deferred components to the same- 
named defined components if exists, then hides the defined components used. 
The formalization given in the next section does not include freeze*. For the 
surface language, we could implement it by combining freeze and hide operations 
with the help of the type system. 

Next wc build marshallers for both a single folder and a list of folders, which 
form recursive data structures: 

type folder — { files: file list; subfldrs: folders } 
and folders — folder list 
Like Syme, we use an intermediate mixin in favor of conciseness, 
mixin FIdrlnnerMrshI = freeze*( 
{ type src = folder type trg — folders 

let f (fis, fidrs) = { files = fis; subfldrs = fidrs } 
let g fid = (fid. files, fid.subfldrs) } ^ 
InnerMrshI) 

Then to build marshallers for folder and folders, wc follow their type definitions, 
by merging constituent mixins and resolving deferred components to defined 
ones: 

mixin FIdrMrshI = close(freeze*( 
(rename(0_(5i^^t;mr5hii^mrshi)) (FilesMrshI)) ^ 

(hidet(rename((sl^5l.52^s2;mr5hlli->mr5hll:mrshl2H^mrshl2). 

(mr5hl_srcH^mrshl>)(PairMrshl))) ^ 

(rena 

'''^( (mrshl_srcH->mrshl_src) , (elrrit~i-t;rrirshl_elmi— i-mrshl;fldMrshli— ^mrshl)) 

(FIdrlnnerMrshI)) ^ 

(rename(^g|i^^g|^.n^|.5hl_elmi-+mrshl_elm), 

(fldr5Mr5hlh-»mr5hl;mrshl2i-+mr5hl;s2i-»t)) (ListMrshI)) 

Thus we have created marshaller FIdrMrshI. fIdrMrshI for a single folder and FI- 
drMrshI. fIdrsMrshI for a list of folders. In the surface language we could provide 
an identity mapping with appropriate domain to improve notational verbosity. 
For the above example, we preferred not to use identity mappings to make 
explicit how deferred components are resolved to defined ones. 

Specifying marshallers for recursive data types such as folder and folders is 
not problematic in the original Haskell context of Kennedy or in our lazy mixin 
context, essentially due to the laziness. But it is problematic in the context of 
the ML core language because of the value recursion restriction. The problem 
is well-discussed in the previous papers of Kennedy and Syme. In short, it is 
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due to ML's intolerance of the following recursive definitiorlfl 

let rec p = pairMrshl(p, intMrshI) 
where we assumed primitive marshaller intMrshI and marshallcr combinator 
pairMrshI given in the library. Note that the abstraction of type marshaller 
is not the root of the problem. Even wc exposed the underlying implementation 
of marshaller, we still face the problem since marshallcrs arc pairs of functions. 

If we consider first-class mixins, i.e. mixins as core values, we could im- 
plement a marshaller as separate functions of marshal action and unmarshal 
action, while ensuring the consistency of constructed marshaller/unmarshaller 
pairs. Our formalization of a lazy mixin calculus is largely abstracted over the 
core language. The core language may support first-class mixins, but we pre- 
ferred the current presentation in favor of generality by not assuming a richer 
core language. Wc also found the current presentation useful to demonstrate a 
possibly interesting scenario where lazy mixins and a call-by- value core language 
are combined to obtain more tolerant recursive definitions. 

3 Lazy mixins 

We start by considering a simpler semantics, where a component of a mixin is 
evaluated when it is projected. The syntax of our lazy mixin calculus, named 
Lyre, is defined in Figure [2] We assume pairwise disjoint sets Merits of iden- 
tifiers. Names of names, and Loc of locations. Components of a mixin are 
internally referred to by (a-convcrtible) identifiers, but externally accessed by 
(non-convertible) names. We use locations to formalize lazy evaluation. 

Notations For a finite mapping /, dom[f) and ran(f) respectively denote 
the domain and range of /. is an empty mapping, that is, dom{9), cod{(ti) and 

ran(jh) are empty sets. The notation bi denotes the finite mapping / such 

that, for all i ^ I, f{a.i) = bi. It is only defined when, for all i, j G I, i ^ j 
implies ^ Oj. Throughout the paper, wc only consider finite mappings, so 
simply say a mapping to mean a finite one. 

For a mapping /, /\a:; is the restriction of / to dom(f)\{x}. 

For mappings /, /', wc write / + /' for the union of / and /'. That is, 
doTn{f + /') = dom{f) U dom{f'), and for all x in dom{f + /'), 

(f ^ f'M-A - / ^^"^'^ ^ ^ dom{f) 

U + / )[-^) - I j/^^,) ^i^gj^ ^ g dom{f) 

f + f is, defined only if dom{f) fi dom{f') = 0. The notation /' o / denotes the 
mapping composition. It is defined only when ran{f) C dom{f'). 

We have explained most of the constructs for mixin expressions in the pre- 
vious section. In the formalization, however, mixin structures take a more 
fundamental form. Precisely, a mixin structure, simply called structure here- 
after, is a triple of input assignment l, output assignment a and local binding 

*Thc example is not ideal in that ML does not allow recursive type definitions such as type 
t = t * int. But the source of the problem should be clear. 
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x,y G Idents 
X,Y G Names 
I G Loc 

E ::= C I M 
M ::= [i;o;p] 

I Ml <- M2 

I 01 < M > (/)2 

hidex{M) 
freeze^ (M) 
c/ose(A'/) 

a; 



C ::= M.X I / 

X I X 

iei Y 

o ::= Xi 1-^ a;i 

p ::= 1-^ 

::= X, 



identifiers 

names 

loeations 

expressions 

mixin structure 

sum 

rename 

hide 

freeze 

close 

projection 
location 

projection, location 
identifier, name 

input assignment 
output assignment 
local binding 
renaming 
tying 

Figure 2: Syntax for Lyre 
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p. The local binding p is a mapping from identifiers to expressions and cor- 
responds to the body of the mixin; if x is in dom{p), then a; is a defined 
component of the mixin with p{x) being the defining expression. p{x) can 
refer to both defined and deferred components of the mixin via identifiers. 
Any identifier in dom{p) and dom{i) is bound in p{x). p{x) must not con- 
tain names. The input assignment t is a mapping from identifiers to names 
and corresponds to declarations of deferred components; a deferred compo- 
nent internally referred to by x is resolved by the name i{x). dom{p) and 
dom{b) must be disjoint. The output assignment o is a mapping from names 
to identifiers; a component of a mixin externally accessed by X is associated 
to o{X) inside the mixin. ran{o) must be a subset of dom{p) U dom{L). Struc- 
tures are identified up to a-renaming of identifiers. The explicit distinction 
between identifiers and names allows identifiers to be renamed by a-conversion, 
while names remain immutable, thus making projection by name unambigu- 
Hirschowitz and Leroy(2005)[ Lillibridge and Harper(1994)| . 
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In agreement with the distinction of identifiers and names, the rename op- 
eration takes two mappings on names, and the hide operation takes a name as 
argument. The freeze operation takes a mapping from names to expressions, 
where expressions may contain names. Mixin expressions contain locations. We 
use locations in the operational semantics to implement lazy evaluation, but 
locations will not appear in the surface language. 

The formalization is mostly independent of the core language. We only 
assume the core language includes projection from mixin expressions, locations, 
identifiers and names. Again locations will not appear in the surface language. 

In Figure [H we define the operational semantics for Lyre. A heap state 
(T is a mapping from locations to heap objects, which arc cither expressions, 
values or error. We formalize lazy evaluation by suspending and memorizing 
evaluation in heap states. We assume given core values v. Then values V are 
either structures or core values. We syntactically distinguish structures as mixin 
expressions, surrounded by square brackets, and as values, surrounded by angle 
brackets. The distinction lets us simplify the formalization. 

The judgment cr h £^ J, {V; CT2) means that in heap state a expression E 
evaluates into value V with heap state being 172 • We assume given inference 
rules to deduce a \- C [ {V\a2) for core expressions other than projections or 
locations. 

Notations We write (T[li ^ k,] to denote a mapping extension. Precisely, 

r, lei T/,,-, { Ki when /' ~ k for some i G / 
= \ a{n otherwise 

The notation is defined only if, for any i,j S /, i j implies li Ij. We 
may write a[l k] when J is a singleton. The notation E[li/xi\i^i denotes the 
substitution of /^'s for x^'s in E for all i G /. The notation is defined only if, for 
any i, j £ I, i ^ j implies .t,; ^ Xj. For input assignment t, tying ip and output 

assignment = Xi Xi, ooip o l is the mapping p such that dom{p) ~ dom{L) 
and, for all x G dom{b), p{x) is the expression obtained from ipoiix) by replacing 
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V ..— {l;o;p) \v values 

K ::= E I error | V heap objects 

a G Loc -fin-> k heap state 

mixin structure 

(1) 



o- 1- [r,o;p] i {{t;o;p);a) 
sum 

a\- Ml I ((ii;oi;pi);cr2) h M2 i ((^2; 02; P2); 0-3) 
dom{pi) n dom{p2) = dom{ii) n dom{i2) = 

Cr h Ml ^ M2 I {{li + L2;Oi+ 02\pi + /32); 0-3) 

rename 
(T h A/ i ((t;o;p);cr2) 



cr h (/)<lM !>(/)' i (((/) o t;oo (/)';p);ct2) 
(ThMi ((t;o;p);CT2) 



(3) 



ah /izdex(M) i ((i;o\X;p};t72) 
/reeze 

ah M [ ((ii + i2;o;p);a2) 
dom{ip) = ran{Li) dom{xJj) D ran{i2) = 
(T h freeze^{M) i ((t2;o; (p + (o o -0 o ii));cr2) 
c/ose 

ahM i ((0; o; E,);a2) V^ G /, fresh 

^ '■ (6) 

a h dose(M) i ((0;o;Xi t^- /i);CT2[^i 1-^ /xj]j^i]) 



(5) 



projection 

ah M i ((t;o;p);a2) a2 h (poo)(X) j (^5^3) 



<j\- M.X iiV;a3) 
location 
ail)^V 



(7) 



cr(Z) = £; o-[Z error] h £; j (V; (72) 



(8) 

(9) 



ThU (i^;'T2[^^l^]) 

Figure 3: Semantics 
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Xi's with Xi's for all i £ /. ooip o l is only defined when ran{t,) C dom{ip) and, 
for all X G dom{L), any name appearing in i/; o is in dom{o). 

Let's look at the inference rules. A structure evaluates into itself and the 
heap state is unchanged (rule llj). The sum operation merges the two operand 
mixins (rule The side conditions ensure that identifiers do not collide and 
are always satisfiablc by taking appropriate a-equivalent mixins. The effect 
of the rename operation is simply compositions of mappings (rule ([3])). The 
hide operation narrows the domain of the output assignment (rule The 
freeze operation resolves deferred components according to the tying ip (rule 
([5])). Precisely, for all x G dom(Li), x is resolved to the expression o o -0 o li{x). 
ijj o ii{x) may contain names, which are replaced with identifiers by o. The 
rule augments the local binding with oo ip o i^i and the input assignment of the 
resulting mixin diminishes accordingly. 

The rule ^ for the close operation is responsible for making mixins lazy. 
Firstly the operand mixin expression must be evaluated into a structure without 
holes. Then, for each defined identifier Xi, a fresh heap location k is allocated to 
store the defining expression Ei, where any occurrence of Xj's in Ei is substituted 
by Ij's. The body of the resulting structure maps Xi to li, thus access to is 
redirected to U. 

To evaluate projection M.X (rule ([7])), M is first evaluated into a structure 
(t; o; p). Then the rule consults o for the associated identifier to X , thus deter- 
mines the expression that M.X accesses by looking up the identifier in p. In the 
normal evaluation, i.e. when projection is made from a closed mixin, p o o{X) 
returns a location, where the defining expression of o{X) is stored. 

The last two rules are for evaluating locations I, and are fairly standard. 
If the heap state contains a value at / (rule ([5|)), then the value is returned 
and the heap state is unchanged. When an expression E is stored at I, then it 
is evaluated. The heap state maps / to error during the evaluation of E, to 
avoid evaluating the same expression repeatedly and to signal an error for cyclic 
definitions. On completion, the heap state is updated with the resulting value. 

It may be useful to note that we do not need evaluation rules for names or 
identifiers, since in the normal evaluation names are substituted by expressions 
and identifiers by locations. 

As one may have noticed, there is potential that evaluation gets stuck. One 
serious source is when projection is made from an open mixin. Instead of pre- 
venting such a scenario at the operational semantics level, we leave it to the type 
system to eliminate the possibilities for evaluation to get stuck. Although we do 
not present a type system in this paper, straightforward adaptation of previous 
work such as Flatt and Felleisen(1998)] is sufficient for this purpose. The type 
system would be able to eliminate other ill-typed scenarios such as an attempt 
to merge mixins with overlapping output names, i.e., dom(oi) n dom(o2) ^ 
in rule We have omitted inference rules for propagating error states, as- 
suming when evaluation encounters an error during deduction, it immediately 
terminates signaling a runtime error. 
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3.1 Call- by-name and eager variants 

Small modifications to evaluation rules let the operational semantics model call- 
by-name and eager evaluation strategies. This subsection presents those vari- 
ants. 

To model a call-by-name strategy, we replace rules ([5]) and ^ with the single 
rule: 

a^ajl) i{V;a2) 

Heap states arc not updated, thus expressions stored are re-evaluated whenever 
accessed. 

By eager evaluation strategy, we mean an evaluation strategy that evaluates 
all components of a mixin at once when the mixin is closed. This is also easily 
implemented by replacing rule ([6]) with: 



ahM i ((0; o; x, E,);a2) I = {1,2, . . . ,n} 
Vi ^ I, li fresh cr' = (72 [ 



(11) 



<jhclose{M) i ([0;o;:r, k];0 



4 Lazy mixins and disciplined effects 

We extend the operational semantics of the previous section so that it takes 
account of constraints on the evaluation order of components of mixins. In 
examples of this section, we use a side-effecting function "print C", which prints 
the resulting value of evaluating C, then returns the value, to visualize the 
evaluation order. 



4.1 Design space of evaluation strategies 

There are several evaluation strategies that we found interesting to consider. 
Below we explain those strategies which we have in mind. 
Firstly we consider the following example: 
mixin Ml = close( 
{ let cl — print 1 let c2 — print 2 
let c3 = print 3 let c4 = print 4 }) 
Top-down strategy We may want components of a mixin to be evaluated fol- 
lowing the textual definition order in which they appear in the source program. 
This constraint will ensure, in the above example, that 1 is printed before 2, and 
2 is before 3, and 3 is before 4. This strategy is reminiscent of ML's strategy. 
Lazy-field and lazy-record strategies If we adopt top-down strategy, we have a 
choice on whether to make accessible components of a mixin immediately after 
they are evaluated, while other components of the mixin arc still to be evaluated 
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consecutively. We call lazy-field strategy the strategy that allows such access 
and lazy-record strategy the strategy that does not allow. Intuitively lazy-field 
strategy treats a closed mixin as a record with lazy fields like { al = lazy (print 
1); a2 = lazy (print 2) }, where "{" and "}" are record constructors of the core 
language here, while lazy-record strategy does as a lazy record like lazy ({ al = 
print 1; a2 = print 2 }). For instance, let's consider executing the program: 

mixin M2 = close ({ let cl = 1 let c2 = 2 * M3.cl }) 
mixin M3 = close ({ let cl = 3 + M2.cl }) 
let main = M2.c2 

We assume, for the explanatory purpose, that a program consists of a sequence 
of mixin definitions plus a core value definition named main, where the top-level 
mixin bindings can be mutually recursive. The execution of the program eval- 
uates the defining expression of main. For the execution of the above program 
to succeed, M2.cl should be accessible to M3.cl before evaluation of M2.c2 is 
completed. Hence the execution succeeds with lazy-field strategy, but it fails 
with lazy-record strategy. Clearly lazy-field strategy is more permissive. Al- 
though restrictive, lazy-record strategy is interesting to consider particularly in 
the presence of finer grained accessibility control, as we will see below. 
Internal and external accessibilities It can be useful to change accessibility to 
components of a mixin depending on whether the access is made inside the same 
mixin or outside. For instance, let us consider the following program: 

mixin M4 = close( 

{ let cl = 1 + 2 let c2 = cl + 4 let c3 = print "ok" }) 
let main = M4.c2 

For the execution to succeed, M4.cl should be accessible to M4.c2 immediately 
after M4.cl is evaluated but before evaluation of M4.c2 is completed. Hence we 
need lazy-field strategy inside M4. However we may want components of M4 
to become accessible outside, only after all components of M4 have been eval- 
uated. In other words, we may want lazy-record strategy outside M4 to make 
sure "ok" is necessarily printed before any component of M4 becomes externally 
accessible. Indeed, in the widget mixins example of Section 12. 2i we envisaged 
this internally-lazy-field cxternally-lazy-rccord strategy. For instance, the com- 
ponent menu of MyGUI should be accessible inside once it is created, to config- 
ure the widget containment hierarchy via functions setMenultems and setMenus. 
However menu should not be accessed outside MyGUI, before the configuration is 
completed, i.e. all components, including anonymous ones, of MyGUI are eval- 
uated. Internally-lazy-field externally-lazy-record strategy is also potentially 
interesting in the light of our experience in programming with ML modules; it 
is sometimes convenient to include anonymous side-effecting expressions at the 
end of a structure for the debugging purpose or to properly initialize mutable 
components of the structure. 

As well as design choices among above strategies, we have a choice on how to 
propagate constraints when merging or closing mixins. In contrast to this vast 
design space, we do not have enough experience in programming with mixins. 
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Plainly we cannot determine at present which strategy is most beneficial in 
practice. Hence we keep our formalization open to strategies. That is, the 
formalization is abstracted over constraints on strategies and can be instantiate 
to express particular strategies. 

4.2 The constraint language 

We use binary relations as our constraint language to express various evaluation 
strategies. We identify binary relations on any set P as sets of pairs of elements 
in P. For instance, the relation {(cl, c2) (c2, c3) (c3, c4)} expresses top-down 
strategy in the first example. The relation {(cl, c3) (c2, c4)} stipulates that 
cl should be evaluated before c3 and c2 before c4. There is no constraint on 
the evaluation order between cl and c2 or c3 and c2. Hence this relation does 
not fix the evaluation order in a unique way. For instance in the first example, 
either of the output "1 2 3 4" or " 2 1 3 4" is compatible with the relation. 

To deal with more expressive strategies, we distinguish three sorts of iden- 
tifiers: (ordinary) identifiers x for controlling the evaluation order; internal 
identifiers x for internal accessibility; external identifiers x for external acces- 
sibility. For instance, the relation {(xi,X2)} stipulates that the component xi 
must be evaluated before the component X2 becomes accessible inside the same 
mixin. Similarly {{xi,X2)} stipulates that xi must be evaluated before X2 be- 
comes accessible outside. We will formalize how relations on these three sorts 
of identifiers control the evaluation order and accessibility later, when we define 
the operational semantics. Below we give a descriptive explanation on how those 
three sorts of identifiers can be used to express strategics wc proposed above. 

If we assign the relation {(cl, c2)} as the constraint to M2 in the second 
example, the execution of the program succeeds. The relation stipulates nothing 
about how M2.cl becomes accessible, implying M2.cl is accessible both inside 
M2 and outside immediately after it is evaluated. If we assign the relation {(cl, 
c2), (c2, cl)} as the constraint to M2, the execution fails. The relation stipulates 
that M2.cl becomes accessible outside M2 only after M2.c2 has been evaluated. 
However M3.cl needs to access M2.cl to be evaluated, and M2.c2 to M3.cl; 
there is a circular dependency. 

Top-down internally-lazy-field extcrnally-lazy-record strategy in the third 
example is expressed by assigning the relation {(cl, c2), (c2, c3), (c3, cl), (c3, 
c2)} as the constraint to M4. Wc remark that there are implicit constraints 
imposed by the semantics, such as (cl, cl) and (cl, cl) (but not (cl, cl)). 
The reason is simple: the component cl must be evaluated before it becomes 
accessible. Hence if the relation included (cl, cl), which introduces a circular 
dependency together with the implicit constraint (cl, cl), the evaluation would 
fail. Precisely, the operational semantics signals an error. The relation {(cl, c2), 
(c2, c3), (c3, cl), (c3, c2) (c3, cl), (c3, c2)} in the third example expresses top- 
down internally-lazy-record externally-lazy-rccord strategy. We have omitted 
including constraints such as (c2, cl), since it is anyway induced from (c2, c3) 
and (c3, cl) by transitivity. Transitivity is imposed by the semantics: if c2 must 
be evaluated before c3, and c3 before cl, then naturally c2 must be evaluated 
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mixin structure 

(12) 



rT;e h [t;o;p;e] j ((t; o; p; 6*); cr; 0) 
sum 

cr;e h I ((ti;oi;pi;6'i);o-2;e2) o-2;e2 h JI/2 i (('-2; 02; P2; 62}; 0-3; 63) 
dom{pi) n dom{p2) = dom(ti) n dom(L2) = 
(t; e h ^ iV/2 i ((ti + (-2; oi + 02; pi + P2; u{dom{i.i) U dom(pi),di, dom.{i.2) U dom{p2), O2)); (T3; ©3) 

rename 

a;ei- Afi {{i;o;p;e); (T2; 62) 

(14) 



(t; 6 h (/ii o i\/ > 02 i ((<?ii o i-;oo (f)2;p;6);a2; 62) 
/lide 

(T;ehMi((t;o;p);(T2;e2) 
(r;e h Mex(M) i ((z,;o\X;p);CT2;e2) ^ 
/reeze 

(t; h J\f I ((ti + 12; o; P; S);a2. 62) dom{'iJj) = ran{ii) dom{ip) n ran(t2) = ' 
cT;eh freeze^{M) I (((.2; o; p + (o o -i/, o tj); 6*); (T2; 62) 
cZose 

CT;ei-Mi ((0;o;x, E^; 9); CT2; 62) 
Vi £ /, fresh 63 = e[li/xi]iei[l'i/£i]i€iV" /xt\iei ^^^^ 

a; e h ciose(i\/) i ((0; o; x, I'/; p{{x, \ i e I}, e));a2[li E,[l'Jxj]j^i][l[ fe' k];&2 U 63) 



(16) 



projection 

(T;eh J/ i ((t;o;p;6>); (72; 62) cr2;e2 h (p°o)(X) j (V;a:V,&3) 
(t;&^ M.X [{y;<J3;Q3) 
location 
a{l) = V 



(18) 



cr;e h / i {V;r7;e) 

il'.,l)ee a[l) = E a[l^Bi:TOT]-(d\{(l',l)}^l' i(V';a2;&2) 'T2[/ £■]; 62 h / i (V; ^3; 63) 



ly(^e a{l) = E o-[i error]; e h E i (V';(T';e') 
a;@^l [(V;a'[l^VlQ') 

Figure 4: Semantics with constraint 
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(20) 



(21) 



before cl. 



4.3 Operational semantics 

We extend a structure with a binary relation on ordinary, internal and external 
identifiers. Precisely, a structure [t; o; p; 9] is now 4-tuple of an input assignment 
t, output assignment o, local binding p, and local constraint 6, where is a 
binary relation on doni{i) U dom{p) U {x \ x £ dom{i) U dom{p)} U {x \ x € 
dom{b) U dom{p)}. Otherwise the syntax is unchanged from Figure [2l We use 
A" as a metavariable for sets of ordinary, internal and external identifiers. 

Wc assume given two functions ii{Xi, 9i) and v{Xi, 6i, X2, O2), where di and 
02 are binary relations on Xi and X2 respectively. ^(^"1,01) returns a binary 
relation on Xi and iy{Xi, 61^X2, 62) does on XiUX2. The operational semantics 
uses fi{Xi,6i) to build local constraints for mixins instantiated by the close 
operation, where Xi is the set of deferred and defined identifiers and 61 the 
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local constraint of the operand mixin. Similarly it uses v{Xi,9i,X2, O2) to build 
local constraints for mixins composed by the sum operation, where Xi (resp. 
X2) is the set of deferred and defined identifiers and Oi (rcsp. 62) is the local 
constraints of the left (rcsp. right) right operand mixin. By not fixing the 
interpretations of fi or we keep the formalization neutral of how to propagate 
local constraints when closing or merging mixins. 

In Figure [4l we present the operational semantics which takes account of 
constraints. We use as a metavariable for global constraints, or binary re- 
lations on locations. The judgment ct; 8 h £^ J, (T^;cr';0') means that under 
global constraint Q with heap state tr expression E evaluates into V , where 
the heap state and global constraint have evolved into a' and 8'. As well as 
heap states, global constraints evolve during evaluation, since new constraints 
are added when a mixin is closed (rule (fT7|) ). The notation 8\{(/',^)} denotes 
set subtraction. The notation I 8 denotes the condition that there is not /' 
such that {V , I) e 8. 

Compared to previous evaluation rules in Figure [31 modifications are made 
on rules ([2]) ([6]), and ([9]), which wc explain in turn. 

As explained above, the sum operation uses the function v to build a local 
constraint for the composed mixin (rule (|13p ). 

When closing a mixin (rule (fT7)) ). three fresh locations li,ll,l'/ are created 
for each defined component Xi of the mixin, in order to separately control the 
evaluation order by Z^'s, internal accessibility by /^'s, and external accessibility 
by I'i's. Four important points to be understood are as follows: 1) The local 
binding of the resulting mixin maps cc^'s to /"'s, i.e. locations for external access; 
2) Evaluation of Ei is suspended at k, where Xi's in Ei are substituted by Z-'s, i.e. 
locations for internal access; 3) The new heap state maps I'^s and Z"'s for internal 
and external accesses to Z^'s to connect the accesses to underlying expressions; 
4) The local constraint 6 is transported to the global constraint, by instantiating 
ordinary, internal and external identifiers to the corresponding locations. The 
notation 6[li/xi]i£i[l'Jxi]i^i[l'^' /'Xi]iizj denotes the binary relation on locations 
obtained from 9 by substituting k's for z^'s , l'^^s for x^'s, and /f s for Xi's, where 
the substitution is performed by regarding a binary relation as a set of pairs. 
The local constraint for the resulting mixin is build by the function fj.. 

We have introduced two new rules ([20|l and (j21|l for evaluating locations, 
replacing the previous rule ([9|), to take the global constraint into account. Rule 
([20]) considers the case where the global constraint stipulates that I' should 
be evaluated before I, as described by the side-condition {I', I) G 8. The rule 
evaluates I' first, while updating the heap state to map I to error and removing 
(/', I) from 8; if the evaluation of E' attempts to evaluate I against the global 
constraint, an error is signaled. On completion of the evaluation, E is restored 
at / and the rule retries to evaluate I. The same rule ()20|) may be applied again, 
when there is another location which should be evaluated before I. Otherwise 
rule (pij) is applicable. When there is no location which must be evaluated before 
as described by the side condition I yi. Q in rule pT|) . then E is evaluated 
immediately. 
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It shall be informative to note that in rule the heap state a is updated 
with error to enforce the evaluation order stipulated by the constraint, while 
in rule (PT|) to detect ill-founded recursion. An important ingredient of the 
formalization is that evaluation of projection M.X always goes through a loca- 
tion. This facilitates to control the evaluation order of components of mixins, 
in terms of a binary relation on locations. It is easily proved that if a{l) = V 
then I 7^ 0. We also remark that the operational semantics, in particular the 
evaluation order, is not necessarily deterministic, depending on the constraint. 
For instance, if we assign a local constraint {(cl, c3), (c2, c4)} to the mixin Ml 
of the first example in Section 14.11 we can build deductions which result in the 
outputs "1 2 3 4" and "2 13 4". Non-determinism is not abnormal, but should 
be thought of as underspecification like the underspecified evaluation order of 
function parameters in some programming languages. 

The operational semantics can be proved sane in the sense that evaluation 
does not diverge due to ill-founded recursion. In other words, when evaluation 
diverges, heap states arc extended infinitely. A heap state is extended only when 
a mixin is closed (rule p7|) ). Hence the heap explosion implies that the close 
operation is used infinitely often. This is similar to a situation where infinite 
recursion of function calls exhausts the stack. 



4.4 An example 

We present an example by instantiating the constraint to express one particular 
evaluation strategy. The strategy is motivated by our previous work on exam- 
ining a lazy evaluation strategy for recursive ML-style module |Nakata(200"9)] . 
The purpose of the example is not to advocate this particular strategy, but to 
deliver the better intuition about how to use the constraint. 
For a structure [t; o; p\ 9], we let 6 be the relation: 

{{xi^Xj) I Xi G dom(p) n IdsC,Xj £ dom{p),i < j} U 
{{xi,xj) I 

Xi G (dom(L) U dom{p)) fl IdsC,Xj G dom{L) U dom(p)} 

Above we have assumed for any xi, Xj, if i < j then the definition or declaration 
for Xi textually precedes that for Xj in the source program. IdsC denotes the 
set of identifiers bounds to core expressions. I.e. we assume Idents consists of 
disjoint sets of identifiers to be bound to core expressions and mixin expressions, 
respectively. 

We give interpretations to functions p and v as follows: 
piX,9)=(l> 

9 u e' u{{x„xj\xieixux')nidsC,Xj exux'} 

The strategy is close to top-down internally-lazy-field externally-lazy-record 
strategy, where sub-mixins are evaluated lazily. Below we explain the strategy 
in detail. 

1. Preceding core components of the same and enclosing mixins are evaluated 
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first. Enclosing mixins may contain other sub-mixins, whose core fields 
need not be evaluated first. This is enforced by including in the local 
constraint of a structure the relation {[xi,Xj) \ Xi S dom{p) D IdsC,Xj € 
dom{p),i < j}. Note that Xj may be bound to a mixin expression, and 
in order to evaluate the expression all core components preceding to it 
must have been evaluated. Thus the constraint controls the evaluation 
order not only of core components of the same mixin but also of those of 
enclosing mixins. 

2. Components of a mixin become accessible inside the same mixin imme- 
diately after they are evaluated, but are accessible outside only after all 
the core components have been evaluated. This is enforced by not having 
constraints mentioning internal identifiers and by including in the local 
constraint of a structure the relation {{xi,xj) \ Xi £ {dom{L) U dom{p)) n 
IdsC,Xj £ dom{i) U dom(p)}. Observe how we propagate the constraint 
on external accessibility when merging mixins by including the relation 
{{xi,'xj \ Xi € {X U X') n IdsC, Xj e X U X'} in the result of ly. 

3. While core components are evaluated following the textual definition or- 
der, there is no constraint on the evaluation order between components 
of merged mixins; u does not introduce {xi,Xj) or {xi,Xj) for any Xi G X 
and Xj S X' . 

4. We do not leave any constraint after a mixin is closed; it is enough to 
enforce the evaluate order once. This is reflected in the interpretation of 
/i. 

As we have said, we do not intend to justify ourselves in choosing this strat- 
egy, because we do not have enough programming experience to do so. Never- 
theless we motivate the strategy below, aiming at posing questions to readers 
about possible concerns one may face in the quest of better design choices. 

The first condition ensures that backward references to core components 
of the same and enclosing mixins are necessarily proper values, but not sus- 
pensions or error's. This provides programmers with a safety guarantee on 
backward references to core components, which seems useful for ML-initiated 
programmers. Interestingly this design choice also bears a similarity to Java's 



class initialization policy Gosling et al.(2005)Gosling, Joy, Steele, and Bracha 



We have already motivated in Section 14.11 the combination of internally-lazy- 
field and externally-lazy-record strategies; internally-lazy-field strategy leaves 
flexibility in intra-mixin recursion, while externally-lazy-record strategy keeps 
the evaluation stable towards outside. A possible drawback of externally-lazy- 
record strategy, compared to externally-lazy-field strategy, is that we may loose 
flexibility in inter-mixin recursion. However we are less concerned by inter-mixin 
recursion, since we believe mixins are designated to support flexible intra-mixin 
recursion; notably the sum and freeze operations are useful for taking flx-points 
inside a mixin. 

We are less confldent in the choice of ly. But it could be useful to keep the 
evaluation order independent between separately defined mixins; it is unlikely 
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that a programmer can foresee in which order components of other mixins to 
be merged with should/could be evaluated. 



4.5 An extension 

There is a strategy which we want to consider, but our constraint language is 
not expressive enough for it. The strategy is a variant on top-down internally- 
lazy-field externally-lazy- field strategy, where we impose an extra constraint, 
called trigger-constraint, that all components of a mixin must be evaluated at 
once before the first access to a component of the mixin returns. For instance, 
let us consider the following program: 

mixin Ml = { 

let cl = print 1 let c2 = M2.c2 

let c3 — print (cl + c2) let c4 = print 5 } 
mixin M2 = { 

let cl = Ml.cl let c2 = print (cl + 1) let c3 = print 4 } 
let main = Ml.c3 

According to the above proposed strategy, the execution succeeds and "12 4 3 
5" is printed. (Recall that "print (1-1-2)" returns 3, after printing 3). Here is 



1. Top-down strategy ensures the printing orders "1 3 5" and "2 4" indepen- 
dently. 

2. Thanks to internally-lazy-field strategy, Ml.c3 and M2.c2 are successfully 
evaluated. 

3. Thanks to externally-lazy-field strategy, evaluation of M2.cl succeeds. 
Note that M2 is forced to evaluate by the access from Ml.c2. Hence 
with externally-lazy- record strategy, the evaluation fails, since Ml.cl is 
not yet accessible outside then. 

4. Finally and importantly, the trigger-constraint ensures that M2.c3 is eval- 
uated before evaluation of Ml.c2 returns and that Ml.c4 is before evalua- 
tion of main returns. This explains why 4 is printed immediately after 2, 
and 5 is after 3. 



This strategy comes from our previous work on lazy recursive modules [Nakatai 



In a recursive modules setting, inter-module recursion is important, hence we 
wanted externally-lazy-field strategy. We found the trigger-constraint useful to 
enforce our design policy that once a module is accessed, all its component are 
eventually evaluated. We want to consider the same strategy as our previous 
proposal in a mixin context, too. Observe that the trigger-constraint only lets 
the access to Ml.c3 trigger evaluation of Ml.c4, but Ml.cl is already accessible 
both inside and outside once it is evaluated. We cannot include any of con- 
straints (c4, c3), (c4, c3), or (c4, c3) in the local constraint of Ml, since the first 
one is inconsistent with top-down strategy, the second with externally-lazy-field 
strategy, the third with intcrnally-lazy-ficld strategy. 



why. 
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n = (e,A) {l,h...l„}eA a-{e,A\{{l,h...l„}})hl l{V;a';U'] 

l^A {r,l)ee a{l)=E 
^ error];(e\{(r,/)}, A) h I' I {V';a2;n2) a2[l i-^ £;] ; Ha h / i {V;^^-]!^) 



a- (e,A)|-a{V;<73;n2) 
n=(e,A) i^A lyke a{l)=E o-[i error]; E l (F;o-';n') 



(23) 



(24) 



a-Tlh M i((%;o;Xi'^ Ei;-n);cT2;n2) tt = (9,6) = (0, A) 



(22) 



a;n\-l l{V-(7'[l^V]:n') 

■,Xi^^ Ei;TT)]a2;U-2) tt = (6 
Vi e I, h I', I'/ fresh e' = e[h/x,],ei[l'Jx,],eiWm,ei A' = 5[h/x,],^i[l'Jx.].^,[l'/ /x-],ei 

C7;n h dose(M) I {{$;o;x, l'l\li({x, \ i e /}, tt)); aafZ, k]\ (6 U O', A U A')) 



Figure 5: Extension with trigger-constraint 



4.5.1 Formalization 

To gain extra expressivity to deal with the trigger-constraint, we extend a local 
constraint to be a pair of a binary relation on identifiers and a set of sets of 
identifiers. Precisely, a structure [t; o; p; tt] now contains a local constraint tt, 
which is a pair (0,5) of a binary relation 9 on dom^L) U dom{p) U {x | .t G 
dom{b) U rfom(p)} U {i | a; G dom{i) U rfo?7i(p)} and a set 5 of sets of elements in 
dom^b) U dom{p). 9 expresses constraints on the evaluation order and accessi- 
bilities as before. 5 expresses the trigger-constraint; if X is in 5, then evaluation 
of all components bound to identifiers in X is triggered at once when any of the 
components is accessed for the first time. For instance when 6 contains dom{p), 
then all defined components of the structure, but deferred ones, are evaluated 
at once when any of the defined components is accessed for the first time. Ac- 
cordingly, a global constraint 11 is now a pair (O, A) of a binary relation 
on locations and set A of sets of locations. The functions p and need to be 
extended to operate on pairs of a binary relation and set of sets. 

To take account of the trigger-constraint, We replace rules ((20|) and ((2T|) by 
rules (1221), ^ and and rule ^ by rule ^ as given in Figure El The 
notation / 0E A denotes the condition that A does not contain a set containing 
I. 

The additional work is to check, before evaluating a location Z, whether 
there are locations whose evaluation is triggered by I. Rule p2l) considers 
the case where / triggers evaluation of k's, as described by the side condi- 
tion {IJi . . An} G A. The rule bears responsibility for evaluating k's and 
{/, /i . . . In} is discharged from A. Except for the side condition I 0E A, rules 
(231) and (211) are identical to previous rules and ([211); the side condition 
ensures that all trigger constraints involving I have been handled. It is easily 
proved that ^9]) and ([22l) are exclusive to each other. Rule ([25ll is a technical 
adjustment, since the rule now needs to transport a pair of a binary relation 
and set of sets from the local constraint to the global constraint. The notation 
S[h/xi]i£i[l'^/xi]i^i[l'/ /xi]i(zj denotes the set of sets of locations obtained from 
6 by substituting li's for x^'s , I'^'s for x^'s, and I'/'s for Xi's. We do not repeat 
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class A { val al = ... } 

class B extends A { val bl = ... val b2 = ... } 
class C extends B { val cl = .. } 
let c — new C 

Figure 6: A class hierarchy 



the other rules; the necessary modification is to replace 0's by II's. 
4.5.2 An example 

As an example of how to use the trigger-constraint, we present a possible object 
initialization strategy in class-based object-oriented languages. The purpose 
of the example is not to explain an encoding of object-oriented language fea- 
tures such as inheritance and overriding, which is already examined in previous 
work Ancona and Zucca (2002)1 . Here we focus on the aspect of object initial- 



ization, by regarding components of a mixin as (instance) fields of an object. In 
this scenario, open mixins correspond to classes and closed mixins to objects. 
We shall not need the full expressivity of Lyre to model standard class-based 
object-oriented languages. For specificity, we restrict ourselves to a fragment of 
the calculus satisfying the following conditions: 

• Structures do not contain sub-mixins. This implies we do not consider 
inner classes. 

• The sum operation only takes open mixins as operands. The operation 
corresponds to inheritance. Then this is standard, since usually classes do 
not inherit from objects, or vice versa. In the sum construct Mi <— M2, 
we assume the left operand mixin Mi corresponds to the superclass and 
the right operand mixin A/2 to the inheriting class. 

For a structure [l;o; p; (6,6)], we assign internally-lazy-record externally- 
lazy-record strategy. The initialization order of fields within an object is kept 
unspecified. That is, we let 9 be the relation: 

{{xijX]) I Xi,Xj G {dom{L) U dom{p))} 
U {{xi,Xj) I £ {dom{i) U dom{p))} 

We let 5 be the singleton: 

{(dom(t) U dom{p))} 

The trigger-constraint 5 above stipulates that all the fields of an object must be 
initialized at once. 

We give interpretations to functions p and v as follows: 

p{x,^)^{m 

v{x,(e,5),x',{e',5'))^ 

(61 U 61' U {{x,,Xj) I Xi e X, Xj e X'}, {{X U X')}) 
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The interpretation of v makes the strategy interesting. Viewed as object 
initialization, the strategy is described as follows. 



1. Fields arc initialized following the class hierarchy. That is, fields of super- 
classes are initialized before those of sub-classes. For instance in Fig- 
ure [HI the field al of the object c is initialized before bl or b2, and 
bl and b2 are before cl. This is imposed by including the constraint 
{(xi, Xj) \ Xi £ X , Xj € X'} in the result of the first element of i/. 

2. Any field inherited from a superclass becomes accessible both inside and 
outside, once all the fields from the superclass are initialized. Hence in 
the example, c.bl and c.b2 become accessible immediately after both have 
been initialized, but before c.cl is initialized. Note that neither of c.bl 
nor c.b2 is accessible even inside before both have been initialized. This 
is specified by the local constraint assigned to a structure. 

3. We assume the new operation for instantiating objects from classes is 
equivalent to the close operation followed by access to some field of the 
mixin closed. For instance we may assume the Object class which resides 
in the root of the class hierarchy, i.e. a superclass of any class, contains 
a special field named init for that purpose. Then the strategy enforces 
the standard object initialization policy where all fields of an object are 
initialized when it is created. This is where we use the trigger-constraint. 
The result {{X U X')} of the second element of ly ensures that all field 
of an object arc initialized at once when init is accessed, since it trig- 
gers initialization of the fields of inheriting classes, when the init field is 
initialized. 

In fact this strategy, in particular the characteristic described second above, 
is inspired by the object initialization strategy of the F# programming lan- 



ject initialization patterns, enhancing safety by eliminating programming styles 
which are often awkward sources for null-pointer exceptions. As a result, the 
strategy is less flexible than that of some object-oriented languages such as Java, 
yet it can still support common programming idioms found in object-oriented 
programming. In short, we found F#'s strategy an interesting example of dis- 
ciplined evaluation orders. 



One difference between previous work and the present work is that each of previ- 
ous work examined an evaluation strategy, while we explored the design space of 
lazy evaluation strategies and give the operational semantics which can deal with 
several strategies. Most related to our work is Ancona and Zucca's call-by-name 

^We believe the strategy presented is close to F#:'s. Yet the exact strategy is under-specified 
in the language documentation. 




F# places restrictions on possible ob- 



5 Related Work 
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mixin calculus Ancona and Zucca(2002)| and Hirs chowitz and Leroy's call-by- 



value mixin calculus Hirschowitz and Leroy(2005)| . Ancona et al. investigated 



the interaction between mixins and computational effect, using a monadic meta- 



language as semantic basis Ancona et al. (2003) Ancona, Fagorzi, Moggi, and Zucca 



We will review the three in detail below. S. Fagorzi and E. Zucca proposed R- 
calculus to allow projection from open mixins in a consistent way 
Fagorzi and Zucca(2007)| ; this is a design direction we have not explored. Our 



previous work proposed a lazy evaluation strategy for recursive ML-style mod- 
ules, which we explained in Section 14.51 Design questions we encountered there 
motivated strategies we proposed in Section [ITT] We do not look back at the 



history of mixins, but only mention a few of influential papers |Bracha(1992) 


Ancona and Zucca(2002) 


Hirschowitz and Leroy(2005)| Duggan and Sourelis(1996)| 


Flatt and Felleisen(1998) 


. In particular, type systems which eliminate unsound 



scenarios such as to close mixins having holes or to select a component from 
an open mixin, have been well-investigated. Those type system proposals are 
orthogonal and complementary to the presented work. 

Call-by-name mixins Ancona and Zucca formalized a mixin calculus, named 
CMS, with call-by-name evaluation using small-step semantics Ancona and Zucca (2002)1 ■ 



The formalization is concise and allows equational reasoning of mixins. However 
the call-by-name semantics might not be suitable to be used with a call-by-value 
core language allowing arbitrary side-effects, such as the ML core language, since 
with the call-by-name semantics evaluation of let rec x = x diverges when x is 
selected and the same side-effect can be produced repeatedly. Large part of the 
formalization in Section [3] is borrowed from CMS. We adapted their small-step 
semantics to big-step semantics. Technically we made a small but important 
modification; in CMS an output assignment maps names to expressions, whereas 
in Lyre names to identifiers. In this way we avoid duplicating expressions in the 
freeze operation. 

Call-by-value mixins Hirschowitz and Leroy formalized a mixin calculus with 
call-by- value evaluation Hirschowitz and Leroy(2005)| . Generally call-by- value 



mixins result in the simplest evaluation order, while lazy mixins are more fiexible 
in handling recursion. For instance, the marshallers example in Section r2 . 3h 'elies 
on the laziness to specify marshallers for recursive data types. We are motivated 
to distinguish open and closed mixins by their work. Apart from the difference 
of call-by-value and lazy, Lyre differs from their calculus in the sum operation 
in that we allow mixins to be merged independently of whether they are closed 
or open, while they only consider the sum operation on open mixins. Our 
design choice is motivated to keep flexibility in sharing side effects. For instance, 
it was useful in MakeSet and MakeMultiSet mixins example from Section [2?T1 
the sharing of counter between Set and MultiSet is achieved by merging the 
closed mixin Key with MakeSet and MakeMultiSet. It should be noted that 
one important objective of Herschowitz and Leroy's work is to statically ensure 
initialization safety of mixins. The objective of our paper is not about static 
guarantees of initialization safety. 
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Ejfectful mixins and equational reasoning Ancona et al. examined the in- 
teraction between mixins and computational effect, by means of a recursive 



monadic binding Ancona et al. (2003) Ancona, Fagorzi, Moggi, and Zucca . The 



sum operation only takes open mixins as argument in their calculus. They sepa- 
rate computational components from non-computational ones, where the former 
are evaluated exactly once, while the latter are re-evaluated whenever they are 
projected. Computational components of a mixin are evaluated at once when 
the mixin is closed by the doall operation, in a similar way to the rule (jlip 
from Section [5?T] To the best of our understanding, their evaluation strategy is 
top-down internally-lazy-field externally-lazy-record strategy, where closed sub- 
mixins are evaluated immediately. When mixins are merged, the computational 
components of the right-operand mixin are evaluated before those of the left- 
operand mixin. The separation of computational components lets them retain 
the CMS equational reasoning. 



6 Conclusion 

We have formalized the operational semantics for a mixin calculus with lazy 
evaluation. We started by considering a simpler semantics where a component 
of a mixin is evaluated when it is projected. Then we extended the semantics 
to impose various restrictions on the evaluation order of and accessibilities to 
components of mixins, by adding local constraint to mixin structures and global 
constraint to the evaluation judgment. We have kept the formalization neutral 
of constraints and it can be instantiated to express several evaluation strategies. 
As well as we considered the design space of strategies, we took a closer look at 
two particular strategies. 

We do not claim the formalization is expressive enough to deal with all in- 
teresting evaluation strategies. At the same time, we do not think it technically 
difficult to extend the formalization to express more strategies. As the exten- 
sion we made in Section [4.51 exemplifies, we may well gain more expressivity by 
extending the constraint language and by adding more evaluation rules. Indeed 
a moot point was to keep the formalization not too complicated without giving 
up too much expressivity to deal with interesting strategies. 
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